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Abstract 


This document forms a certificate profile, based on RFC 3280, for 
identity certificates issued to natural persons. 


The profile defines specific conventions for certificates that are 
qualified within a defined legal framework, named Qualified 
Certificates. However, the profile does not define any legal 
requirements for such Qualified Certificates. 


The goal of this document is to define a certificate profile that 
supports the issuance of Qualified Certificates independent of local 


legal requirements. The profile is however not limited to Qualified 
Certificates and further profiling may facilitate specific local 
needs. 
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1. Introduction 


March 2004 
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This specification is one part of a family of standards for the X.509 
Public Key Infrastructure (PKI) for the Internet. 


[X.509] and [RFC 3280], 


It is based on 
which defines underlying certificate formats 


and semantics needed for a full implementation of this standard. 


This profile includes specific mechanisms intended for use with 


Qualified Certificates. 


The term Qualified Certificates and the 


assumptions that affect the scope of this document are discussed in 


Section 2. 
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Section 3 defines requirements on certificate information content. 
This specification provides profiles for two certificate fields: 
issuer and subject. It also provides profiles for four certificate 
extensions defined in RFC 3280: subject alternate name, subject 
directory attributes, certificate policies, and key usage, and it 
defines two additional extensions: biometric information and 
qualified certificate statements. The certificate extensions are 
presented in the 1997 Abstract Syntax Notation One (ASN.1) [X.680], 
but in conformance with RFC 3280 the 1988 ASN.1 module in Appendix A 
contains all normative definitions (the 1997 module in Appendix A is 
informative). 


In Section 4, some security considerations are discussed in order to 
clarify the security context in which the standard may be utilized. 


Appendix A contains all relevant ASN.1 structures that are not 
already defined in RFC 3280. Appendix B contains a note on 
attributes. Appendix C contains an example certificate. 


The appendices sections are followed by the References, Authors 
Addresses, and the Full Copyright Statement. 


1.1. Changes since RFC 3039 


This specification obsoletes RFC 3039. This specification differs 
from RFC 3039 in the following basic areas: 


* Some editorial clarifications have been made to introductory 
sections to clarify that this profile is generally applicable 
to a broad type of certificates, even if its prime purpose is 
to facilitate issuance of Qualified Certificates. 


* To align with RFC 3280, support for domainComponent and title 
attributes in subject names are included, and postalAddress is 
no longer supported. 


* To align with actual usage, support for the title attribute in 
the subject directory attributes extension is no longer 
supported. 


* To better facilitate broad applicability of this profile, some 
constraints on key usage settings in the key usage extension 
have been removed. 


* A new qc-Statement reflecting this second version of the 
profile has been defined in Section 3.2.6.1. This profile 
obsoletes RFC 3039, but the qc-statement reflecting compliance 
with RFC 3039 is also defined for backwards compatibility. 
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1.2. Definitions 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in BCP 14, [RFC 2119]. 


2. Requirements and Assumptions 


The term "Qualified Certificate" is used by the European Directive on 
Electronic Signature [EU-ESDIR] to refer to a specific type of 
certificates, with appliance in European electronic signature 
legislation. This specification is intended to support this class of 
certificates, but its scope is not limited to this application. 


within this standard, the term "Qualified Certificate" is used 
generally, describing a certificate whose primary purpose is to 
identify a person with a high level of assurance, where the 
certificate meets some qualification requirements defined by an 
applicable legal framework, such as the European Directive on 
Electronic Signature [EU-ESDIR]. The actual mechanisms that decide 
whether a certificate should or should not be considered a "Qualified 
Certificate" in regard to any legislation are outside the scope of 
this standard. 


Harmonization in the field of identity certificates issued to natural 
persons, in particular Qualified Certificates, is essential within 
several aspects that fall outside the scope of RFC 3280. The most 
important aspects that affect the scope of this specification are: 


- Definition of names and identity information in order to identify 
the associated subject in a uniform way. 


- Definition of information which identifies the CA and the 
jurisdiction under which the CA operates when issuing a particular 


certificate. 


- Definition of key usage extension usage for Qualified 
Certificates. 


- Definition of information structure for storage of biometric 
information. 


- Definition of a standardized way to store predefined statements 
with relevance for Qualified Certificates. 


- Requirements for critical extensions. 
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2.1. Properties 


This profile accommodates profiling needs for Qualified Certificates 
based on the assumptions that: 


- Qualified Certificates are issued by a CA that makes a statement 
that the certificate serves the purpose of a Qualified 
Certificate, as discussed in Section 2.2. 


- The Qualified Certificate indicates a certificate policy 
consistent with liabilities, practices, and procedures undertaken 


by the CA, as discussed in Section 2.3. 


- The Qualified Certificate is issued to a natural person (living 
human being). 


- The Qualified Certificate contains a name which may be either 
based on the real name of the subject or a pseudonym. 


2.2. Statement of Purpose 
This profile defines conventions to declare within a certificate that 
it serves the purpose of being a Qualified Certificate. This enables 
the CA to explicitly define this intent. 
The function of this declaration is thus to assist any concerned 
entity in evaluating the risk associated with creating or accepting 
signatures that are based on a Qualified Certificate. 


This profile defines two ways to include this information: 


- As information defined by a certificate policy included in the 
certificate policies extension, and 


- As a statement included in the Qualified Certificates Statements 
extension. 


2.3. Policy Issues 


Certain policy aspects define the context in which this profile is to 
be understood and used. It is however outside the scope of this 
profile to specify any policies or legal aspects that will govern 
services that issue or utilize certificates according to this 
profile. 


It is however an underlying assumption in this profile that a 


responsible issuing CA will undertake to follow a certificate policy 
that is consistent with its liabilities, practices, and procedures. 
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2.4. Uniqueness of names 


Distinguished name is originally defined in X.501 [X.501] as a 
representation of a directory name, defined as a construct that 
identifies a particular object from among a set of all objects. The 
distinguished name MUST be unique for each subject entity certified 
by the one CA as defined by the issuer name field, for the whole life 
time of the CA. 


3. Certificate and Certificate Extensions Profile 


This section defines certificate profiling conventions. The profile 
is based on the Internet certificate profile RFC 3280, which in turn 
is based on the X.509 version 3 format. For full implementation of 
this section, implementers are REQUIRED to consult the underlying 
formats and semantics defined in RFC 3280. 


ASN.1 definitions, relevant for this section that are not supplied by 
RFC 3280, are supplied in Appendix A. 


3.1. Basic Certificate Fields 


This section provides additional details regarding the contents of 
two fields in the basic certificate. These fields are the issuer and 
subject fields. 


3.1.1. Issuer 


The issuer field SHALL identify the organization responsible for 
issuing the certificate. The name SHOULD be an officially registered 
name of the organization. 


The distinguished name of the issuer SHALL be specified using an 
appropriate subset of the following attributes: 


domainComponent; 
countryName; 
stateOrProvinceName; 
organizationName; 
localityName; and 
serialNumber. 


The domainComponent attribute is defined in [RFC 2247], all other 
attributes are defined in [RFC 3280] and [X.520]. 


Additional attributes MAY be present, but they SHOULD NOT be 
necessary to identify the issuing organization. 
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A relying party MAY have to consult associated certificate policies 
and/or the issuer’s CPS, in order to determine the semantics of name 
fields. 


3.1.2. Subject 


The subject field of a certificate compliant with this profile SHALL 
contain a distinguished name of the subject (see 2.4 for definition 
of distinguished name). 


The subject field SHALL contain an appropriate subset of the 
following attributes: 


domainComponent; 
countryName; 
commonName; 

surname; 

givenName; 

pseudonym; 
serialNumber; 

title; 
organizationName; 
organizationalUnitName; 
stateOrProvinceName; and 
localityName. 


The domainComponent attribute is defined in [RFC 2247], all other 
attributes are defined in [RFC 3280] and [X.520]. 


Other attributes MAY also be present; however, the use of other 
attributes MUST NOT be necessary to distinguish one subject name from 
another subject name. That is, the attributes listed above are 
sufficient to ensure unique subject names. 


Of these attributes, the subject field SHALL include at least one of 
the following: 


Choice I:  commonName 
Choice II: givenName 
Choice III: pseudonym 


The countryName attribute value specifies a general context in 
which other attributes are to be understood. The country 
attribute does not necessarily indicate the subject’s country of 
citizenship or country of residence, nor does it have to indicate 
the country of issuance. 
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Note: Many X.500 implementations require the presence of countryName 
in the DIT. In cases where the subject name, as specified in the 
subject field, specifies a public X.500 directory entry, the 
countryName attribute SHOULD always be present. 


The commonName attribute value SHALL, when present, contain a name 
of the subject. This MAY be in the subject’s preferred 
presentation format, or a format preferred by the CA, or some 
other format. Pseudonyms, nicknames, and names with spelling 
other than defined by the registered name MAY be used. To 
understand the nature of the name presented in commonName, 
complying applications MAY have to examine present values of the 
givenName and surname attributes, or the pseudonym attribute. 


Note: Many client implementations presuppose the presence of the 
commonName attribute value in the subject field and use this value to 
display the subject’s name regardless of present givenName, surname, 
or pseudonym attribute values. 


The surname and givenName attribute types SHALL be used in the 
subject field if neither the commonName attribute nor the 
pseudonym attribute is present. In cases where the subject only 
has a givenName, the surname attribute SHALL be omitted. 


The pseudonym attribute type SHALL, if present, contain a 
pseudonym of the subject. Use of the pseudonym attribute MUST NOT 
be combined with use of any of the attributes surname and/or 
givenName. 


The serialNumber attribute type SHALL, when present, be used to 
differentiate between names where the subject field would 
otherwise be identical. This attribute has no defined semantics 
beyond ensuring uniqueness of subject names. It MAY contain a 
number or code assigned by the CA or an identifier assigned by a 
government or civil authority. It is the CA’s responsibility to 
ensure that the serialNumber is sufficient to resolve any subject 
name collisions. 


The title attribute type SHALL, when present, be used to store a 
designated position or function of the subject within the 
organization specified by present organizational attributes in the 
subject field. The association between the title, the subject, 
and the organization is beyond the scope of this document. 


The organizationName and the organizationalUnitName attribute 


types SHALL, when present, be used to store the name and relevant 
information of an organization with which the subject is 


Santesson, et al. Standards Track [Page 8] 


RFC 3739 Qualified Certificates Profile March 2004 


associated. The type of association between the organization and 
the subject is beyond the scope of this document. 


The stateOrProvinceName and the localityName attribute types 
SHALL, when present, be used to store geographical information 
with which the subject is associated. If an organizationName 
value is also present, then the stateOrProvinceName and 
localityName attribute values SHALL be associated with the 
specified organization. The type of association between the 
stateOrProvinceName and the localityName and either the subject or 
the organizationName is beyond the scope of this document. 


Compliant implementations SHALL be able to interpret the attributes 
named in this section. 


3.2. Certificate Extensions 


This section provides additional details regarding the contents of 
four certificate extensions defined in RFC 3280: Subject Alternative 
Name, Subject directory attributes, Certificate policies, and Key 
usage. This section also defines two additional extensions: 
biometric information and qualified certificate statements. 


3.2.1. Subject Alternative Name 


If the subjectAltName extension is present, and it contains a 
directoryName name, then the directoryName MUST follow the 
conventions specified in section 3.1.2 of this profile. 


3.2.2. Subject Directory Attributes 


The subjectDirectoryAttributes extension MAY be present and MAY 
contain additional attributes associated with the subject, as a 
complement to present information in the subject field and the 
subject alternative name extension. 


Attributes suitable for storage in this extension are attributes 
which are not part of the subject’s distinguished name, but which MAY 
still be useful for other purposes (e.g., authorization). 


This extension MUST NOT be marked critical. 


Compliant implementations SHALL be able to interpret the following 
attributes: 


dateOfBirth; 


placeOfBirth; 
gender; 
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countryOfCitizenship; and 
countryOfResidence. 


Other attributes MAY be included according to local definitions. 


The dateOfBirth attribute SHALL, when present, contain the value 
of the date of birth of the subject. The manner in which the date 
of birth is associated with the subject is outside the scope of 
this document. The date of birth is defined in the 
GeneralizedTime format and SHOULD specify GMT 12.00.00 (noon) down 
to the granularity of seconds, in order to prevent accidental 
change of date due to time zone adjustments. For example, a birth 
date of September 27, 1959 is encoded as "195909271200002". 
Compliant certificate parsing applications SHOULD ignore any time 
data and just present the contained date without any time zone 
adjustments. 


The placeOfBirth attribute SHALL, when present, contain the value 
of the place of birth of the subject. The manner in which the 
place of birth is associated with the subject is outside the scope 
of this document. 


The gender attribute SHALL, when present, contain the value of the 
gender of the subject. For females the value "F" (or "f"), and 
for males the value "M" (or "m"), have to be used. The manner in 
which the gender is associated with the subject is outside the 
scope of this document. 


The countryOfCitizenship attribute SHALL, when present, contain 
the identifier of at least one of the subject’s claimed countries 
of citizenship at the time the certificate was issued. If more 
than one country of citizenship is specified, each country of 
citizenship SHOULD be specified through a separate, single-valued 
countryOfCitizenship attribute. Determination of citizenship is a 
matter of law and is outside the scope of this document. 


The countryOfResidence attribute SHALL, when present, contain the 
value of at least one country in which the subject is resident. 

If more than one country of residence is specified, each country 
of residence SHOULD be specified through a separate, single-valued 
countryOfResidence attribute. Determination of residence is a 
matter of law and is outside the scope of this document. 
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3.2.3. Certificate Policies 


The certificate policies extension SHALL be present and SHALL contain 
the identifier of at least one certificate policy which reflects the 
practices and procedures undertaken by the CA. The certificate 
policy extension MAY be marked critical. 


Information provided by the issuer stating the purpose of the 
certificate, as discussed in Section 2.2, SHOULD be evident through 
indicated policies. 


The certificate policies extension MUST include all policy 
information needed for certification path validation. If policy 
related statements are included in the QCStatements extension (see 
3.2.6), then these statements SHOULD also be contained in the 
identified policies. 


Certificate policies MAY be combined with any qualifier defined in 
RFC 3280. 


3.2.4. Key Usage 


The key usage extension SHALL be present. Key usage settings SHALL 
be set in accordance with RFC 3280 definitions. Further requirements 
on key usage settings MAY be defined by local policy and/or local 
legal requirements. 


The key usage extension SHOULD be marked critical. 
3.2.5. Biometric Information 


This section defines an OPTIONAL extension for storage of biometric 
information. Biometric information is stored in the form of a hash 
of a biometric template. 


The purpose of this extension is to provide a means for the 
authentication of biometric information. The biometric information 
that corresponds to the stored hash is not stored in this extension, 
but the extension MAY include a URI (sourceDataUri) that references a 
file containing this information. 


If included, the URI MUST use the HTTP scheme (http://) [HTTP/1.1] or 
the HTTPS scheme (https://) [RFC 2818]. Since the fact that 
identifying data is being checked may itself be sensitive 
information, those deploying this mechanism may also wish to consider 
using URIs which cannot be easily tied by outsiders to the identities 
of those whose information is being retrieved. 
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Use of the URI option presumes that the data encoding format of the 
file content is determined through means outside the scope of this 
specification, such as file naming conventions and metadata inside 
the file. Use of this URI option does not imply that it is the only 
way to access this information. 


It is RECOMMENDED that biometric information in this extension be 
limited to information types suitable for human verification, i.e., 
where the decision of whether the information is an accurate 
representation of the subject is naturally performed by a person. 
This implies a usage where the biometric information is represented 
by, for example, a graphical image displayed to the relying party, 
which MAY be used by the relying party to enhance identification of 
the subject. 


This extension MUST NOT be marked critical. 
biometricInfo EXTENSION ::= { 
SYNTAX BiometricSyntax 
IDENTIFIED BY id-pe-biometricInfo } 


id-pe-biometricInfo OBJECT IDENTIFIER ::= {id-pe 2} 


BiometricSyntax ::= SEQUENCE OF BiometricData 


BiometricData ::= SEQUENCE { 
typeOfBiometricData TypeOfBiometricData, 
hashAlgorithm AlgorithmIdentifier, 
biometricDataHash OCTET STRING, 
sourceDataUri IA5String OPTIONAL } 


TypeOfBiometricData ::- CHOICE { 
predefinedBiometricType PredefinedBiometricType, 
biometricDataID OBJECT IDENTIFIER } 


PredefinedBiometricType ::= INTEGER { picture(0), 
handwritten-signature (1) } (picture|handwritten-signature,...) 


The predefined biometric type picture, when present, SHALL identify 
that the source picture is in the form of a displayable graphical 
image of the subject. The hash of the graphical image SHALL be 
calculated over the whole referenced image file. 


The predefined biometric type handwritten-signature, when present, 
SHALL identify that the source data is in the form of a displayable 
graphical image of the subject’s handwritten signature. The hash of 
the graphical image SHALL be calculated over the whole referenced 
image file. 
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3.2.6. Qualified Certificate Statements 


This section defines an OPTIONAL extension for the inclusion of 
statements defining explicit properties of the certificate. 


Each statement SHALL include an object identifier for the statement 
and MAY also include optional qualifying data contained in the 
statementInfo parameter. 


If the statementInfo parameter is included, then the object 
identifier of the statement SHALL define the syntax and SHOULD define 
the semantics of this parameter. If the object identifier does not 
define the semantics, a relying party may have to consult a relevant 
certificate policy or CPS to determine the exact semantics. 


This extension may be critical or non-critical. If the extension is 
critical, this means that all statements included in the extension 
are regarded as critical. 


qcStatements EXTENSION ::= { 
SYNTAX OCStatements 
IDENTIFIED BY id-pe-qcStatements } 


-- NOTE: This extension does not allow to mix critical and 
-- non-critical Qualified Certificate Statements. Either all 
-- statements must be critical or all statements must be 

-- non-critical. 


id-pe-qcStatements OBJECT IDENTIFIER ::= { id-pe 3 } 
OCStatements ::- SEQUENCE OF QCStatement 
QCStatement ::- SEQUENCE { 


statementId QC-STATEMENT.&Id((SupportedStatements]), 
statementInfo QC-STATEMENT.&Type 
({SupportedStatements}{@statementId}) OPTIONAL } 


SupportedStatements QC-STATEMENT ::= { qcStatement-1,...} 


A statement suitable for inclusion in this extension MAY be a 
statement by the issuer that the certificate is issued as a Qualified 
Certificate in accordance with a particular legal system (as 
discussed in Section 2.2). 


Other statements suitable for inclusion in this extension MAY be 
statements related to the applicable legal jurisdiction within which 
the certificate is issued. As an example, this MAY include a maximum 
reliance limit for the certificate indicating restrictions on CA’s 
liability. 
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3.2.6.1. Predefined Statements 


The certificate statement (id-qcs-pkixQCSyntax-v1), identifies 
conformance with requirements defined in the obsoleted RFC 3039 
(Version 1). This statement is thus provided for identification of 
old certificates issued in conformance with RFC 3039. This statement 
MUST NOT be included in certificates issued in accordance with this 
profile. 


This profile includes a new qualified certificate statement 
(identified by the OID id-qcs-pkixQCSyntax-v2), identifying 
conformance with requirements defined in this profile. This 
Qualified Certificate profile is referred to as version 2, while RFC 
3039 is referred to as version 1. 


qcStatement-1 QC-STATEMENT ::= { SYNTAX SemanticsInformation 
IDENTIFIED BY id-qcs-pkixQCSyntax-v1 } 

-- This statement identifies conformance with requirements 

-- defined in RFC 3039 (Version 1). This statement may 

-- optionally contain additional semantics information as 

-- specified below. 


qcStatement-2 QC-STATEMENT ::- ( SYNTAX SemanticsInformation 
IDENTIFIED BY id-qcs-pkixQCSyntax-v2 } 

-- This statement identifies conformance with requirements 

-- defined in this Qualified Certificate profile 

-- (Version 2). This statement may optionally contain 

-- additional semantics information as specified below. 


SemanticsInformation ::- SEQUENCE { 
semanticsIdentifier OBJECT IDENTIFIER OPTIONAL, 
nameRegistrationAuthorities NameRegistrationAuthorities 


OPTIONAL } 
(WITH COMPONENTS {..., semanticsIdentifier PRESENT} | 
WITH COMPONENTS {..., nameRegistrationAuthorities PRESENT}) 


NameRegistrationAuthorities ::= SEQUENCE SIZE (1..MAX) OF 
GeneralName 


The SementicsInformation component identified by id-qcs- 
pkixOCSyntax-vl MAY contain a semantics identifier and MAY identify 
one or more name registration authorities. 


The semanticsIdentifier component, if present, SHALL contain an OID, 
defining semantics for attributes and names in basic certificate 
fields and certificate extensions. The OID may define semantics for 
all, or for a subgroup of all present attributes and/or names. 
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The NameRegistrationAuthorities component, if present, SHALL contain 
a name of one or more name registration authorities, responsible for 
registration of attributes or names associated with the subject. The 
association between an identified name registration authority and 
present attributes MAY be defined by a semantics identifier OID, by a 
certificate policy (or CPS), or some other implicit factors. 


If a value of type SemanticsInformation is present in a OCStatement 
where the statementID component is set to id-qcs-pkix-OCSyntax-vl or 
id-qcs-pkix-QCSyntax-v2, then at least one of the semanticsIdentifier 
or nameRegistrationAuthorities fields must be present, as indicated. 
Note that the statementInfo component need not be present in a 
QCStatement value even if the statementID component is set to id- 
qes-pkix-OCSyntax-vl or id-qcs-pkix-QCSyntax-v2. 


4. Security Considerations 


The legal value of a digital signature that is validated with a 
Qualified Certificate will be highly dependent upon the policy 
governing the use of the associated private key. Both the private 
key holder, as well as the relying party, should make sure that the 
private key is used only with the consent of the legitimate key 
holder. 


Since the public keys are for public use with legal implications for 
involved parties, certain conditions should exist before CAs issue 
certificates as Qualified Certificates. The associated private keys 
must be unique for the subject, and must be maintained under the 
subject's sole control. That is, a CA should not issue a qualified 
certificate if the means to use the private key is not protected 
against unintended usage. This implies that the CA has some 
knowledge about the subject's cryptographic module. 


The CA must further verify that the public key contained in the 
certificate is legitimately representing the subject. 


CAs should not issue CA certificates with policy mapping extensions 
indicating acceptance of another CA's policy unless these conditions 
are met. 


Combining the nonRepudiation bit in the keyUsage certificate 
extension with other keyUsage bits may have security implications 
depending on the context in which the certificate is to be used. 
Applications validating electronic signatures based on such 
certificates should determine whether the present key usage 
combination is appropriate for their use. 
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The ability to compare two qualified certificates to determine if 
they represent the same physical entity is dependent on the semantics 
of the subjects’ names. The semantics of a particular attribute may 
be different for different issuers. Comparing names without 
knowledge of the semantics of names in these particular certificates 
may provide misleading results. 


This specification is a profile of RFC 3280. The security 


considerations section of that document applies to this specification 
as well. 
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A. ASN.1 Definitions 


As in RFC 3280, ASN.1 modules are supplied in two different variants 
of the ASN.1 syntax. 


Appendix A.1 is in the 1988 syntax, and does not use macros. 

However, since the module imports type definitions from modules in 
RFC 3280 which are not completely in the 1988 syntax, the same 
comments as in RFC 3280 regarding its use applies here as well; i.e., 
Appendix A.1 may be parsed by an 1988 ASN.I-parser by removing the 
definitions for the UNIVERSAL types and all references to them in RFC 
3280’s 1988 modules. 


Appendix A.2 is in the 1997 syntax. 


In case of discrepancies between these modules, the 1988 module is 
the normative one. 


A.1. 1988 ASN.1 Module (Normative) 

PKIXqualified88 {iso(1) identified-organization(3) dod(6) 
internet (1) security(5) mechanisms(5) pkix(7) id-mod (0) 
id-mod-qualified-cert (31) } 

DEFINITIONS EXPLICIT TAGS ::= 

BEGIN 

-- EXPORTS ALL -- 

IMPORTS 

GeneralName 
FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) 
internet (1) security(5) mechanisms (5) pkix(7) id-mod (0) 
id-pkixl-implicit (19) } 

AlgorithmIdentifier, DirectoryString, AttributeType, id-pkix, id-pe 
FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) 
internet (1) security(5) mechanisms (5) pkix(7) id-mod (0) 
id-pkixl-explicit (18) }; 

-- Locally defined OIDs 


-- Arc for QC personal data attributes 
id-pda OBJECT IDENTIFIER ::= { id-pkix 9 } 
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-- Arc for QC statements 
id-qcs OBJECT IDENTIFIER ::= { id-pkix 11 } 


-- Personal data attributes 


id-pda-dateOfBirth AttributeType = { id-pda 1 } 
DateOfBirth ::= GeneralizedTime 
id-pda-placeOfBirth AttributeType = { id-pda 2 } 
PlaceOfBirth ::= DirectoryString 

id-pda-gender AttributeType ::= { id-pda 3 } 
Gender ::= PrintableString (SIZE(1)) 


FEN "M", TE "m" or Ten 
id-pda-countryOfCitizenship AttributeType ::= { id-pda 4 } 
CountryOfCitizenship ::- PrintableString (SIZE (2)) 

-- ISO 3166 Country Code 
id-pda-countryOfResidence AttributeType ::= { id-pda 5 ) 
CountryOfResidence ::- PrintableString (SIZE (2)) 

-- ISO 3166 Country Code 
-- Certificate extensions 


-- Biometric info extension 


id-pe-biometricInfo OBJECT IDENTIFIER ::= {id-pe 2} 


BiometricSyntax ::- SEQUENCE OF BiometricData 


BiometricData ::- SEQUENCE { 
typeOfBiometricData  TypeOfBiometricData, 
hashAlgorithm AlgorithmIdentifier, 
biometricDataHash OCTET STRING, 
sourceDataUri IA5String OPTIONAL } 


TypeOfBiometricData ::- CHOICE { 
predefinedBiometricType PredefinedBiometricType, 
biometricDataOid OBJECT IDENTIFIER } 


PredefinedBiometricType ::- INTEGER { 
picture(0), handwritten-signature (1) } 
(picture |handwritten-signature) 
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-- QC Statements Extension 

-- NOTE: This extension does not allow to mix critical and 
-- non-critical Qualified Certificate Statements. Either all 
-- statements must be critical or all statements must be 

-- non-critical. 


id-pe-qcStatements OBJECT IDENTIFIER ::= { id-pe 3} 
OCStatements ::= SEQUENCE OF QCStatement 
QCStatement ::- SEQUENCE { 

statementId OBJECT IDENTIFIER, 

statementInfo ANY DEFINED BY statementId OPTIONAL) 


-- QC statements 

id-qcs-pkixQCSyntax-v1 OBJECT IDENTIFIER ::= { id-qcs 1 } 

-- This statement identifies conformance with requirements 

-- defined in RFC 3039 (Version 1). This statement may 

-- optionally contain additional semantics information as specified 
-- below. 


id-qcs-pkixQCSyntax-v2 OBJECT IDENTIFIER ::= { id-qcs 2 } 
-- This statement identifies conformance with requirements 
-- defined in this Qualified Certificate profile 

-- (Version 2). This statement may optionally contain 

-- additional semantics information as specified below. 


SemanticsInformation  ::- SEQUENCE { 
semanticsIndentifier OBJECT IDENTIFIER OPTIONAL, 
nameRegistrationAuthorities NameRegistrationAuthorities OPTIONAL 
) -- At least one field shall be present 


NameRegistrationAuthorities ::- SEQUENCE SIZE (1..MAX) OF GeneralName 
END 
A.2. 1997 ASN.1 Module (Informative) 
PKIXqualified97 {iso(1) identified-organization(3) dod(6) 
internet (1) security(5) mechanisms (5) pkix(7) id-mod (0) 
id-mod-qualified-cert-97(35) } 
DEFINITIONS EXPLICIT TAGS ::= 


BEGIN 


-- EXPORTS ALL -- 
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IMPORTS 


informationFramework, 


Qualified Certificates Profile 


authenticationFramework, 


usefulDefinitions(0) 3 } 


ub-name 


certificateExtensions, 
upperBounds, 
FROM UsefulDefinitions í(joint-iso-itu-t (2) 


FROM UpperBounds upperBounds 


GeneralName 
FROM CertificateExtensions certificateExtensions 


ATTRIBUTE, AttributeType 
FROM InformationFramework informationFramework 


DirectoryString 


ds (5) 


FROM SelectedAttributeTypes selectedAttributeTypes 


AlgorithmIdentifier, 


id-pkix 


FROM PKIX1Explicit88 { iso(1) 


internet (1) security(5) mechanisms (5) 


LA 


id-pe 


id-pkixl-explicit (18) }; 


-- Locally defined OIDs 


-- Arc for QC personal data 


id-pda 


OBJECT IDENTIFIER ::= 


-- Arc for QC statements 
OBJECT IDENTIFIER ::= 


id-qcs 


-- Personal data attributes 


id-pda-dateOfBirth 
id-pda-placeOfBirth 


id-pda-gender 


id-pda-countryOfCitizenship 
id-pda-countryOfResidence 


Extension, EXTENSION 
FROM AuthenticationFramework authenticationFramework 


attributes 


( id-pkix 9 } 


( id-pkix 11 ) 


AttributeType ::= 
AttributeType ::= 


AttributeType ::= 


-- Certificate extensions 


id-pe-biometricInfo 
id-pe-qcStatements O] 


Santesson, 


et al. 


AttributeType ::= 
AttributeType ::= 


OBJECT IDENTIFIER 


BJECT IDENTIFIER 


Standards Track 


pkix (7) 


BARS c4 oc 


id-pda 
id-pda 
id-pda 
id-pda 
id-pda 


Oe WN H 


— T eon) 
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selectedAttributeTypes, 
id-at 
module (1) 


identified-organization(3) dod(6) 
id-mod (0) 


{ id-pe 2 } 
{ id-pe 3 } 
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-- QC statements 


id-qcs-pkixQCSyntax-v1 OBJECT IDENTIFIER 
id-qcs-pkixQCSyntax-v2 OBJECT IDENTIFIER 


( id-qcs 1 ) 
( id-qcs 2 ) 


-- Personal data attributes 


dateOfBirth ATTRIBUTE ::= { 
WITH SYNTAX GeneralizedTime 
ID id-pda-dateOfBirth } 
placeOfBirth ATTRIBUTE ::= { 
WITH SYNTAX DirectoryString {ub-name} 
ID id-pda-placeOfBirth } 
gender ATTRIBUTE ::= { 
WITH SYNTAX PrintableString (SIZE(1) ^ FROM("M"|"F"|"m"|"£")) 
ID id-pda-gender } 
countryOfCitizenship ATTRIBUTE ::= { 
WITH SYNTAX PrintableString (SIZE (2)) 
(CONSTRAINED BY ( -- ISO 3166 codes only -- }) 
ID id-pda-countryOfCitizenship ) 
countryOfResidence ATTRIBUTE ::= { 
WITH SYNTAX PrintableString (SIZE (2)) 
(CONSTRAINED BY ( -- ISO 3166 codes only -- }) 
ID id-pda-countryOfResidence } 


-- Certificate extensions 
-- Biometric info extension 


biometricInfo EXTENSION ::= { 
SYNTAX BiometricSyntax 
IDENTIFIED BY id-pe-biometricInfo } 


BiometricSyntax ::= SEQUENCE OF BiometricData 


BiometricData ::= SEQUENCE { 
typeOfBiometricData TypeOfBiometricData, 
hashAlgorithm AlgorithmIdentifier, 
biometricDataHash OCTET STRING, 
sourceDataUri IA5String OPTIONAL, 

-- For future extensions -- } 


TypeOfBiometricData ::= CHOICE { 
predefinedBiometricType PredefinedBiometricType, 
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biometricDataOid OBJECT IDENTIFIER } 
PredefinedBiometricType ::- INTEGER { 
picture(0), handwritten-signature (1) } 


(picture |handwritten-signature,...) 


-- QC Statements Extension 

-- NOTE: This extension does not allow to mix critical and 
-- non-critical Qualified Certificate Statements. Either all 
-- statements must be critical or all statements must be 

-- non-critical. 


qcStatements EXTENSION ::= { 
SYNTAX OCStatements 
IDENTIFIED BY id-pe-qcStatements } 


QCStatements ::= SEQUENCE OF QCStatement 


OCStatement ::- SEQUENCE { 
statementId OC-STATEMENT.&id({SupportedStatements}), 
statementInfo QC-STATEMENT.&Type 
({SupportedStatements}{@statementId}) OPTIONAL } 


QC-STATEMENT ::= CLASS { 
&id OBJECT IDENTIFIER UNIQUE, 
&Type OPTIONAL } 
WITH SYNTAX { 
[SYNTAX &Type] IDENTIFIED BY &id } 


qcStatement-1 QC-STATEMENT ::= { SYNTAX SemanticsInformation 
IDENTIFIED BY id-qcs-pkixQCSyntax-v1] 
-- This statement identifies conformance with requirements 
-- defined in RFC 3039 (Version 1). This statement 
-- may optionally contain additional semantics information 
-- as specified below. 


qcStatement-2 QC-STATEMENT ::- ( SYNTAX SemanticsInformation 
IDENTIFIED BY id-qcs-pkixQCSyntax-v2] 
-- This statement identifies conformance with requirements 
-- defined in this Qualified Certificate profile 
-- (Version 2). This statement may optionally contain 
-- additional semantics information as specified below. 


SemanticsInformation ::- SEQUENCE { 
semanticsIdentifier OBJECT IDENTIFIER OPTIONAL, 
nameRegistrationAuthorities NameRegistrationAuthorities OPTIONAL 
)(WITH COMPONENTS {..., semanticsIdentifier PRESENT} | 
WITH COMPONENTS {..., nameRegistrationAuthorities PRESENT}) 
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NameRegistrationAuthorities ::= SEQUENCE SIZE (1..MAX) OF GeneralName 


-- The following information object set is defined to constrain the 
-- set of attributes applications are required to recognize as QCSs. 


SupportedStatements QC-STATEMENT ::= { 

qcStatement-1 | 

qcStatement-2 , ... -- For future extensions -- ) 
END 


B. A Note on Attributes 


This document defines several new attributes, both for use in the 
subject field of issued certificates and in the 
subjectDirectoryAttributes extension. A complete definition of these 
new attributes (including matching rules), along with object classes 
to support them in LDAP-accessible directories, can be found in 

PKCS 9 [RFC 2985]. 


C. Example Certificate 
This section contains the ASN.1 structure, an ASN.1 dump, and the 
DER-encoding of a certificate issued in conformance with this 
profile. The example has been developed with the help of the OSS 


ASN.1 compiler. The certificate has the following characteristics: 


1. The certificate is signed with RSA and the SHA-1 hash 


algorithm 

2. The issuer's distinguished name is (using the syntax specified 
in [RFC 2253]): O=GMD - Forschungszentrum Informationstechnik 
GmbH, C-DE 

3. The subject's distinguished name is (using the syntax 
Specified in [RFC 2253]): GN=Petra+SN=Barzin, O-GMD 


- Forschungszentrum Informationstechnik GmbH, C-DE 


4. The certificate was issued on 1 February, 2004 and will expire 
on 1 February, 2008 


5. The certificate contains a 1024 bit RSA key 


6. The certificate includes a critical key usage extension 
exclusively indicating non-repudiation 


7. The certificate includes a certificate policy identifier 


extension indicating the practices and procedures undertaken 
by the issuing CA (object identifier 1.3.36.8.1.1). The 
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certificate policy object identifier is defined by TeleTrust, 
Germany. 


8. The certificate includes a subject directory attributes 
extension containing the following attributes: 


date of birth: October, 14th 1971 
place of birth: Darmstadt 

country of citizenship:Germany 

gender: Female 


9. The certificate includes a qualified statement certificate 
extension indicating that the naming registration authority’s 


name is "municipality@darmstadt.de". 


10. The certificate includes, in conformance with RFC 3280, an 
authority key identifier extension. 


C.1. ASN.1 Structure 


C.1.1. Extensions 


Since extensions are DER-encoded already when placed in the structure 
to be signed, they are, for clarity, shown here in the value notation 
defined in [X.680]. 


C.1.1.1. The subjectDirectoryAttributes Extension 


certSubjDirAttrs AttributesSyntax ::= { 
{ 
type id-pda-countryOfCitizenship, 
values { 
PrintableString : "DE" 
} 


type id-pda-gender, 
values { 

PrintableString : "F" 
} 


type id-pda-dateOfBirth, 
values { 

GeneralizedTime : "1971101412002" 
} 


Santesson, et al. Standards Track [Page 24] 


RFC 3739 Qualified Certificates Profile 


type id-pda-placeOfBirth, 
values { 

DirectoryString : utf8String : "Darmstadt" 
} 


} 

C.1.1.2. The keyUsage Extension 
certKeyUsage KeyUsage ::= {nonRepudiation} 

C.1.1.3. The certificatePolicies Extension 
certCertificatePolicies CertificatePoliciesSyntax ::= { 


{ 
policyIdentifier {1 3 36 8 1 1} 


} 
} 


C.1.1.4. The qcStatements Extension 
certQCStatement QCStatements ::= { 


{ 
statementId id-qcs-pkixQCSyntax-v2, 


statementInfo SemanticsInformation : { 
nameRegistrationAuthorities { 
rfc822Name : "municipality@darmstadt.de" 


} 


} 
C.1.1.5. The authorityKeyIdentifier Extension 


certAKI AuthorityKeyIdentifier ::= { 


March 2004 


keyIdentifier '000102030405060708090A0B0CODOEOFFEDCBA98'H 


} 


C.1.2. The Certificate 


The signed portion of the certificate is shown here in the value 
notation defined in [X.680]. Note that extension values are already 
DER encoded in this structure. Some values have been truncated for 


readability purposes. 
certCertInfo Certificatelnfo ::= { 


version v3, 
serialNumber 1234567890, 
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signature 
{ 
algorithm { 1 2 840 113549 115}, 
parameters RSAParams : NULL 
by 
issuer rdnSequence 
f 
f 


type (2 5 4 6 }, 
value PrintableString : "DE" 


type (2 5 4 10 }, 
value UTF8String 


} 
}, 


validity 

{ 
notBefore utcTime : "0402011000002", 
notAfter utcTime : "0802011000002" 


}, 
subject rdnSequence 


{ 
{ 


type {25 4 6 }, 
value PrintableString : "DE" 


type (2 5 4 10 }, 
value UTF8String 
"GMD Forschungszentrum Informationstechnik GmbH" 


type {2544|}, 

value UTF8String : "Barzin" 
}, 
{ 


type ( 2 5 4 42 }, 
value UTF8String : "Petra" 
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} 
by 
subjectPublicKeyInfo 
f 
algorithm 
f 
algorithm ( 1 2 840 113549 1 11}, 
parameters RSAParams : NULL 
}, 
subjectPublicKey '30818902818100DCE74CD5...0203010001'H 
by 
extensions 
f 
f 
extnId (2 5 29 9 }, -- subjectDirectoryAttributes 
extnValue '305B301006082B0601050507090...7374616474'H 
by 
f 


extnId (2 5 29 15 }, -- keyUsage 
critical TRUE, 
extnValue ” 03020640” H 


extnId { 2 5 29 32 }, -- certificatePolicies 
extnValue '3009300706052B24080101'H 


extnId { 2 5 29 35 }, -- authorityKeyIdentifier 
extnValue '30168014000102030405060708090A0BO0CODOEOFFEDCBA98'H 


extnId (136155713 }, -- qcStatements 
extnValue '302B302906082B06010505070B0...4742E6465 'H 


C.2. ASN.1 Dump 
This section contains an ASN.1 dump of the signed portion of the 
certificate. Some values have been truncated for readability 


purposes. 


CertificateInfo SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 633 


version : tag = [0] constructed; length = 3 
Version INTEGER: tag = [UNIVERSAL 2] primitive; length - 1 
2 
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serialNumber CertificateSerialNumber INTEGER: tag = [UNIVERSAL 2] 
primitive; length = 4 

1234567890 
signature AlgorithmIdentifier SEQUENCE: tag = [UNIVERSAL 16] 
constructed; length = 13 

algorithm OBJECT IDENTIFIER: tag = [UNIVERSAL 6] 


primitive; length = 9 
{ 1 2 840 113549 115} 
parameters OpenType 
NULL 
issuer Name CHOICE 
rdnSequence RDNSequence SEQUENCE OF: tag = [UNIVERSAL 16] 
constructed; length = 72 
RelativeDistinguishedName SET OF: tag 
constructed; length = 11 
AttributeTypeAndValue SEQUENCE: tag 
constructed; length = 9 


[UNIVERSAL 17] 


[UNIVERSAL 16] 


type OBJECT IDENTIFIER: tag = [UNIVERSAL 6] 
primitive; length = 3 
(2 5 4 6 } -- id-at-countryName 
value PrintableString 
" DE " 
RelativeDistinguishedName SET OF: tag = [UNIVERSAL 17] 


constructed; length = 57 
AttributeTypeAndValue SEQUENCE: tag 
constructed; length = 55 


[UNIVERSAL 16] 


type OBJECT IDENTIFIER: tag = [UNIVERSAL 6] 
primitive; length = 3 
{ 25 4 10 } -- id-at-organizationName 


value UTF8String 
"GMD Forschungszentrum Informationstechnik GmbH" 
validity Validity SEQUENCE: tag = [UNIVERSAL 16] 
constructed; length = 30 
notBefore Time CHOICE 
utcTime UTCTime: tag 
0402011000002 
notAfter Time CHOICE 
utcTime UTCTime: tag 
0802011000002 
subject Name CHOICE 
rdnSequence RDNSequence SEQUENCE OF: tag = [UNIVERSAL 16] 
constructed; length = 101 
RelativeDistinguishedName SET OF: tag 
constructed; length = 11 
AttributeTypeAndValue SEQUENCE: tag 
constructed; length = 9 
type OBJECT IDENTIFIER: tag = [UNIVERSAL 6] 
primitive; length = 3 


[UNIVERSAL 23] primitive; length 13 


[UNIVERSAL 23] primitive; length = 13 


[UNIVERSAL 17] 


[UNIVERSAL 16] 
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{ 2546 } -- id-at-countryName 
value PrintableString 
" DE " 


RelativeDistinguishedName SET OF: tag [UNIVERSAL 17] 
constructed; length = 55 
AttributeTypeAndValue SEQUENCE: tag 


constructed; length = 53 


[UNIVERSAL 16] 


type OBJECT IDENTIFIER: tag = [UNIVERSAL 6] 
primitive; length = 3 
(2 5 4 10 } -- id-at-organizationName 


value UTF8String 
"GMD Forschungszentrum Informationstechnik GmbH" 


RelativeDistinguishedName SET OF: tag = [UNIVERSAL 17] 
constructed; length = 29 
AttributeTypeAndValue SEQUENCE: tag = [UNIVERSAL 16] 
constructed; length = 13 
type OBJECT IDENTIFIER: tag = [UNIVERSAL 6] 
primitive; length = 3 
{ 25 4 4 } -- id-at-surname 
value UTF8String 
"Barzin" 
AttributeTypeAndValue SEQUENCE: tag = [UNIVERSAL 16] 
constructed; length = 12 
type OBJECT IDENTIFIER: tag = [UNIVERSAL 6] 
primitive; length = 3 
{ 25 4 42 } -- id-at-givenName 
value UTF8String 
"Petra" 
subjectPublicKeyInfo SubjectPublicKeyInfo SEQUENCE: 
tag = [UNIVERSAL 16] constructed; length = 159 
algorithm AlgorithmIdentifier SEQUENCE: tag = [UNIVERSAL 16] 
constructed; length = 13 
algorithm OBJECT IDENTIFIER: tag = [UNIVERSAL 6] 
primitive; length = 9 
{ 1 2 840 113549 11 1 } -- rsaEncryption 
parameters OpenType 
NULL 
subjectPublicKey BIT STRING: tag = [UNIVERSAL 3] 


primitive; length - 141 
0x0030818902818100dce74cd5ald55aeb0lcf5ecc20f3c3fca787... 


extensions : tag = [3] constructed; length = 233 
Extensions SEQUENCE OF: tag = [UNIVERSAL 16] 
constructed; length = 230 

Extension SEQUENCE: tag = [UNIVERSAL 16] 
constructed; length = 100 
extnId OBJECT IDENTIFIER: tag = [UNIVERSAL 6] 
primitive; length = 3 
{ 25 29 9 } -- id-ce-subjectDirectoryAttributes 
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extnValue OCTET STRING: tag = [UNIVERSAL 4] 
primitive; length = 93 
0x305b301006082b06010505070904310413024445300f06082... 
Extension SEQUENCE: tag = [UNIVERSAL 16] 
constructed; length = 14 
extnId OBJECT IDENTIFIER: tag = [UNIVERSAL 6] 
primitive; length = 3 


(2 5 29 15 } -- id-ce-keyUsage 
critical BOOLEAN: tag = [UNIVERSAL 1] primitive, length - 1 
TRUE 


extnValue OCTET STRING: tag = [UNIVERSAL 4] 
primitive, length - 4 
0x03020640 
Extension SEQUENCE: tag = [UNIVERSAL 16] 
constructed; length = 18 
extnId OBJECT IDENTIFIER: tag = [UNIVERSAL 6] 
primitive; length = 3 
(2 5 29 32 } -- id-ce-certificatePolicies 
extnValue OCTET STRING: tag = [UNIVERSAL 4] 
primitive; length = 11 
0x3009300706052b24080101 
Extension SEQUENCE: tag = [UNIVERSAL 16] 
constructed; length = 31 
extnId OBJECT IDENTIFIER: tag = [UNIVERSAL 6] 
primitive; length = 3 
(2 5 29 35 } -- id-ce-authorityKeyIdentifier 
extnValue OCTET STRING: tag = [UNIVERSAL 4] 
primitive; length = 24 
Ox30168014000102030405060708090a0b0c0d0e0ffedcba98 
Extension SEQUENCE: tag = [UNIVERSAL 16] 
constructed, length - 57 
extnId OBJECT IDENTIFIER: tag = [UNIVERSAL 6] 
primitive, length - 8 
(1361 5 5 7 1 3 } -- id-pe-qcStatements 
extnValue OCTET STRING: tag = [UNIVERSAL 4] 
primitive, length - 45 
0x302530290608250601050507000230148301581196d756e696... 


C.3 DER-encoding 
This section contains the full, DER-encoded certificate, in hex. 


30820310 30820279 A0030201 02020449 9602D230 0D06092A 864886F7 0D010105 
05003048 310B3009 06035504 06130244 45313930 37060355 040A0C30 474D4420 
2D20466F 72736368 756E6773 7A656E74 72756D20 496E666F 726D6174 696F6E73 
74656368 6E696B20 476D6248 301E170D 30343032 30313130 30303030 5A170D30 
38303230 31313030 3030305A 3065310B 30090603 55040613 02444531 37303506 
0355040A 0C2E474D 4420466F 72736368 756E6773 7A656E74 72756D20 496E666F 
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726D6174 696F6E73 
65747261 300D0603 
01010105 0003818D 
A787CFCB 571A21AA 
B3A9926A 8FO8EA00 
EDDC73B5 94FAAOEF 
5F2F7EBD BC3EFOA6 
1D09045D 305B3010 
05070903 31031301 
34313230 3030305A 
74300E06 03551D0F 
2B240801 01301F06 
OEOFFEDC BA983039 
0B02301D 301B8119 
65300D06 092A8648 
EFEOF20F 6C558890 
95B08826 EAF3FF1F 
BC36991F 21436520 
B882B39F E1A16A90 


C.4. CA’s Public 
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74656368 
5504040C 
00308189 
8A20AD5D 
FDC3A8F2 
E595C612 
04F6B404 
06082B06 
46301D06 
30170608 
0101FF04 
03551D23 
06082B06 
6D756E69 
86F70D01 
A6E73118 
5917C80B 
E9064761 
AE1A80B8 


RSA Key 


6E696B20 
06426172 
02818100 
FF015130 
BBO16DEC 
A6AE5B8C 
01176925 
01050507 
082B0601 
2B060105 
04030206 
04183016 
01050507 
63697061 
01050500 
8359B9C7 
B4836129 
D932D871 
A9676518 


476D6248 
7A696E30 
DCE74CD5 
DE724E5E 
A3B9411B 
7FO0CA19C 
02030100 
09043104 
05050709 
05070902 
40301206 
80140001 
0103042D 
6C697479 
03818100 
8CE71C92 
CFE5563E 
F71FFEBD 
B5AA7E97 


311D300C 06035504 
819F300D 06092A86 
A1D55AEB O1CF5ECC 
D3F95392 E7BB16C4 
A2599A2A 8CB655C6 
EC4FE7AB 60546768 
01A381E9 3081E630 
13024445 300F0608 
01311118 0F313937 
310B0C09 4461726D 
03551D20 040B3009 
02030405 06070809 
302B3029 06082B06 
40646172 6D737461 
8F8C80BB B2D86B75 
0C66C600 53FBC924 
78592B5B BOF9ACB5 
AD648FA7 CF3C1BCO 
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2A0C0550 
4886F70D 
20F3C3FC 
A71D0F31 
DFEA2 5BF 
4BB2387D 
64060355 
2B060105 
31313031 
73746164 
30070605 
OAOBOCOD 
01050507 
64742E64 
F4E21F82 
825090F2 
2915F0F2 
96F112D4 


This section contains the DER-encoded public RSA key of the CA who 
It is included with the purpose of 


signed the example certificate. 
simplifying verifications of the example certificate. 


30818902818100c88f4bdb66f713ba3dd7a9069880e888d4321acb53cda7fcdf 
da895834e254305956d46a438baa6798035af30db378424e00a829650125b10524 
f9cf0b3f83bell6cd8a36957dc3f54cbd7c58a10c380b3dfal15bd2922ea8660£f 
96e16034d481357c0442ad607c516148083d919£d5307c1c3fa6dfead0e6410999e 


8b8a8411d525dd0203010001 
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